perm filename CLSUBS.MSG[COM,LSP]4 blob
sn#787319 filedate 1985-02-17 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Introduction
C00005 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:
CL-Subsets@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLSUBS.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Subsets-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Beau Sheil Xerox sheil@xerox
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Bob Kessler Univ. of Utah kessler@utah-20
Jay Lark Teknowledge lark@sumex
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC gbrown@dec-marlboro
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂23-Sep-84 1624 RPG Introduction
To: cl-subsets@SU-AI.ARPA
Welcome to the Common Lisp Subsets Subgroup.
In order to mail to this group, send to the address:
CL-Subsets@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLSUBS.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Subsets-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Beau Sheil Xerox sheil@xerox
Dave Matthews HP matthews.hplabs@csnet-relay (I hope)
Bob Kessler Univ. of Utah kessler@utah-20
Jay Lark Teknowledge lark@sumex
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC gbrown@dec-marlboro
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete.
∂27-Sep-84 0737 DUGGAN@UTAH-20.ARPA Please add me ty your group
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84 07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA
I work with Bob Kessler at the University of Utah.
Jerry Duggan
-------
∂02-Oct-84 1316 RPG Chairman
To: cl-subsets@SU-AI.ARPA
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.
The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show.
Any takers?
-rpg-
∂04-Oct-84 1435 GRISS%hp-hulk.csnet@csnet-relay.arpa Chairman
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:35:10 PDT
Received: from hplabs by csnet-relay.csnet id a011122; 4 Oct 84 17:26 EDT
Received: by HP-VENUS id AA16508; Wed, 3 Oct 84 06:38:31 pdt
Message-Id: <8410031338.AA16508@HP-VENUS>
Date: Wed 3 Oct 84 06:38:36-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Chairman
To: cl-subsets%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
I am willing to act as chairman/co-ordinator of the cl-subsets group.
I am currently exploring to what degree PSL (with appropriate
modifications) could be viewed as a CL subset. The version of PSL we
use at HP and some universities, has a significant CL compatibility
module (package system, pathnames, new reader, etc.). With some
changes, and the installation of this module in the basic system, a
useful and fast "PSL strength" subset could be evolved. We are writing
a simple translator to aid the transition from "old" PSL to "new" PSL.
I will first submit an initial proposal to the PSL and Standard LISP
communities for discussion, and then share the revised versions and
comments with the rest of our working group.
Are there any other subset proposals/partial compatibility packages or
translators (from subset to subset) being "brewed" out there?
Martin Griss
-------
∂13-Oct-84 1447 RPG Chairman
To: cl-subsets@SU-AI.ARPA
No one has been nominated as chairman of the Subsets subgroup. I will
need either a volunteer or a nomination. Please respond by October 24. At
the end of this month I want to see some ideas and proposals coming in on
this mailing list.
-rpg-
∂17-Oct-84 1138 jrg@cmu-cs-spice.arpa Re: Chairman
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 11:38:33 PDT
Date: Wednesday, 17 October 1984 11:53:23 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: Dick Gabriel <RPG@su-ai.arpa>
cc: cl-subsets@su-ai.arpa
Subject: Re: Chairman
Message-ID: <1984.10.17.15.52.41.Joseph.Ginder@cmu-cs-spice.arpa>
I thought Martin Griss volunteered for this. Did he not?
--Joe
∂17-Oct-84 1258 WHOLEY@CMU-CS-C.ARPA Chairman
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 12:57:51 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Wed 17 Oct 84 15:52:39-EDT
Date: Wed, 17 Oct 1984 15:25 EDT
Message-ID: <WHOLEY.12056214685.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: cl-subsets@SU-AI.ARPA, Dick Gabriel <RPG@SU-AI.ARPA>
CC: Joseph.Ginder@CMU-CS-SPICE.ARPA
Subject: Chairman
In-reply-to: Msg of 17 Oct 1984 11:53-EDT from Joseph.Ginder at cmu-cs-spice.arpa
Joe's right. The following is in the archives...
-------------------------------------------------------------------------------
Date: Wed 3 Oct 84 06:38:36-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Chairman
To: cl-subsets%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
I am willing to act as chairman/co-ordinator of the cl-subsets group.
I am currently exploring to what degree PSL (with appropriate
modifications) could be viewed as a CL subset. The version of PSL we
use at HP and some universities, has a significant CL compatibility
module (package system, pathnames, new reader, etc.). With some
changes, and the installation of this module in the basic system, a
useful and fast "PSL strength" subset could be evolved. We are writing
a simple translator to aid the transition from "old" PSL to "new" PSL.
I will first submit an initial proposal to the PSL and Standard LISP
communities for discussion, and then share the revised versions and
comments with the rest of our working group.
Are there any other subset proposals/partial compatibility packages or
translators (from subset to subset) being "brewed" out there?
Martin Griss
-------------------------------------------------------------------------------
∂17-Oct-84 1437 marti@randgr Re: Chairman
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 14:37:29 PDT
Received: by randgr.ARPA; Wed, 17 Oct 84 14:09:40 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410172109.AA13976@randgr.ARPA>
Date: 17 Oct 84 14:09:35 PDT (Wed)
To: cl-subsets@su-ai
Subject: Re: Chairman
Martin Griss has volunteered to act as chairman. If there needs to be a
formal nomination, then:
I nominate Martin Griss to the job of acting chairman of the Common Lisp
Subset Committee.
Jed Marti
∂23-Oct-84 0632 jrg@cmu-cs-spice.arpa Re: Import and Export
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 23 Oct 84 06:32:27 PDT
Date: Tuesday, 23 October 1984 09:25:42 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: cl-foreign-function-call@su-ai.arpa
cc: Tom Kaczmarek <KACZMAREK@usc-isif.arpa>, cl-subsets@su-ai.arpa
Subject: Re: Import and Export
Message-ID: <1984.10.23.12.56.30.Joseph.Ginder@cmu-cs-spice.arpa>
The CMU approach does allow other languages to make remote procedure calls
to Common Lisp. I don't see that the issue of a minimal kernel is
particularly relevant to this. For a foreign language to make calls on
Common Lisp does not require that the Lisp it is calling have some specific
functionality more than that it is there and can be called. I certainly
don't expect to define what functions are avaliable in fortran libraries in
order to define a foreign funcall mechanism for Common Lisp; I don't see how
anything different is implied by the reverse situation.
When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC. We then force a GC and save the new,
application-specific lisp core. The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much. I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.
To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable? We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).
--Joe
∂23-Oct-84 1515 Faunt%hp-thor.csnet@csnet-relay.arpa removal form list
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Oct 84 15:14:45 PDT
Received: from hplabs by csnet-relay.csnet id as05924; 23 Oct 84 17:56 EDT
Received: by HP-VENUS id AA29013; Tue, 23 Oct 84 13:33:08 pdt
Message-Id: <8410232033.AA29013@HP-VENUS>
Date: Tue 23 Oct 84 13:32:54-PDT
From: Doug <Faunt%hplabs.csnet@csnet-relay.arpa>
Subject: removal form list
To: cl-foreign-function-call%su-ai.arpa@csnet-relay.arpa,
cl-foreign-function-call-request%su-ai.arpa@csnet-relay.arpa,
cl-subsets%su-ai.arpa@csnet-relay.arpa,
cl-subsets-request%su-ai.arpa@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Please remove dcm%hplabs@csnet-relay (or other equivalent address)
from your list, since this user doesn't exist here by that name,
and I'm tired of looking at the error messages.
-------
∂24-Oct-84 2036 WWHITE@SRI-KL.ARPA ad-hoc vs. planned subsets.
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 24 Oct 84 20:36:47 PDT
Date: Wed 24 Oct 84 20:36:45-PDT
From: Bill <WWHITE@SRI-KL.ARPA>
Subject: ad-hoc vs. planned subsets.
To: cl-subsets@SU-AI.ARPA
When we are concerned about supplying a minimal lisp for some application at
Perq (and CMU), we just load whatever application stuff there is into a lisp
and disembowel the lisp in such a way as to make all of the Common Lisp stuff
that isn't used available for GC. We then force a GC and save the new,
application-specific lisp core. The real problem then, becomes knowing what
minimal stuff the foreign language will call in order not to disembowel too
much. I don't really have much of a feel for how important such minimal
lisps are; I think this a task of the subset committee.
The problem I see with this approach is that it is ad-hoc for
each individual application. In all likelyhood, trying to combine
programs developed separately, will produce less and less savings
as the number of independent pieces goes up.
To the subset committee: I can imagine applications where the delivery
vehicle for a lisp application is a fairly limited piece of hardware; is a
subset appropriate or would the method described above be acceptable? We've
found that very straightforward methods of reducing a lisp core's size
result in dramatic space reductions; more thoughtful approaches should
result in really small lisps for delivery of applications without requiring
a specific minimal subset (although a "kernel" subset might be useful for
other reasons).
As I see it, the real reason for having well defined subsets is
to increase the ability to intgrate work from many places successfully.
Bill White
-------
∂25-Oct-84 1043 marti@randgr Re: ad-hoc vs. planned subsets.
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 10:43:13 PDT
Received: by randgr.ARPA; Thu, 25 Oct 84 10:24:51 pdt
From: Jed Marti <marti@randgr>
Message-Id: <8410251724.AA11533@randgr.ARPA>
Date: 25 Oct 84 10:24:47 PDT (Thu)
To: cl-subsets@su-ai.ARPA
Cc: randgr!hearn@randgr
Subject: Re: ad-hoc vs. planned subsets.
In-Reply-To: Your message of Wed 24 Oct 84 20:36:45-PDT.
<8410250339.AA24984@rand-unix.ARPA>
Reasons for CL subsets:
Another reason for subsets is the efficiency issue. Many of our application
programs are incredibly slow, to the point where the programs are being
rewritten in other languages. We spent two frustrating man years
converting a large Interlisp program into C (still not complete), the sole
reason being speed. I cannot justify the view that once an application is
developed it should be converted into a static procedural language for
efficiency. It is too costly and fosters the conviction that it should have
been written in that medium in the first place.
I believe that a CL subset designed for speed is one that best serves
embedded applications:
1) a fast subset has fewer function calls to a smaller "library"
2) it has a better chance of being CONSless than a system with hidden
mechanisms
3) the human interface can be isolated and extracted when not needed
Jed Marti MARTI@RAND-UNIX
∂25-Oct-84 1534 WHOLEY@CMU-CS-C.ARPA ad-hoc vs. planned subsets.
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Oct 84 15:34:34 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 25 Oct 84 18:32:17-EDT
Date: Thu, 25 Oct 1984 18:32 EDT
Message-ID: <WHOLEY.12058345878.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Jed Marti <marti@RANDGR.ARPA>
Cc: cl-subsets@SU-AI.ARPA, randgr!hearn@RANDGR.ARPA
Subject: ad-hoc vs. planned subsets.
In-reply-to: Msg of 25 Oct 1984 13:24-EDT from Jed Marti <marti at randgr>
One of the properties of Lisp is that it is VERY easy to write VERY inefficient
programs by choosing inappropriate data structures. In older Lisps,
programmers were forced to use inappropriate data structures because things
like strings and vectors weren't around. In addition to the good old Lisp
objects like symbols and conses, Common Lisp provides the data structures that
any other modern programming language provides, and a few useful high-level
data structures (such as hash tables).
A Lisp programmer must choose his data structures well, as must any programmer.
I think it is the burden of the implementor to prevent the "primitives" from
incuring any non-obvious runtime penalties. I am an implementor, and I live
with that burden.
Given a good choice of data structures and algorithms, there is no real reason
why a Common Lisp program should run significantly slower than an equivalent
program written in a procedural language. A case in point: The Spice Lisp text
editor, Hemlock, is significantly faster (doing things like text modification
and redisplay) than Oil, a text editor written in Pascal running on the same
machine -- a machine designed to run Pascal! A lot of careful planning went
into Hemlock, and that planning payed off. Hemlock does much more than Oil,
and is easily extensible because it is written in Lisp.
A member of our user community here wrote a number of useful CAD tools in Perq
Pascal, and has since been turned-on to Common Lisp. He tells me that he can
develop programs many times quicker than he could in Pascal, and that the
performance lost by running them in Lisp instead of Pascal is less than 30%,
and sometimes 0%.
By limiting yourself to a subset with a "fast library" and few primitives, you
risk omitting a language feature that might be exactly right for some
application. I'm willing to bet that a good Common Lisp implementation will
provide that feature more efficiently than a subset with that feature kludged
on as an afterthought.
I can't help thinking that a good deal of the "incredible" slowness of the
application programs you mentioned is due partly to the Interlisp language,
which has been known to provide features at the expense of efficiency -- a fine
thing if you've got a Dorado in your office. Common Lisp claims heritage to
MacLisp, which put greater emphasis on efficiency.
I don't see how that fact that program X runs slowly in Lisp Y has anything to
do with making subsets of Lisp Z. There are a lot of free variables there.
--Skef
∂27-Oct-84 2155 RPG Hello folks
To: cl-subsets@SU-AI.ARPA
We now have a chairman of the subsets subgroup: Martin Griss
of HP. I think he will make an excellent chairman. For your
information I am including the current members of the mailing list.
I will now let Martin take over responsibility for the discussion.
Dave Matthews HP "hpfclp!subsets%hplabs"@csnet-relay
Stan Shebs Utah shebs@utah-20
John Foderaro Berkeley jkf@ucbmike.arpa
Jerry Duggan Univ of Utah duggan@utah-20
Rod Brooks MIT "brooks%oz"@mc
Skef Wholey CMU Wholey@cmuc
Martin Griss HP griss.hplabs@csnet-relay
Beau Sheil Xerox sheil@xerox
Bob Kessler Univ. of Utah kessler@utah-20
Bill White Teknowledge WWhite@sri-kl
Carl Hewitt MIT hewitt-subsets@mc
Govind Deshpande JPL deshpande@jpl-vlsi.arpa
Gary Brown DEC brown@dec-hudson
Eric Benson Lucid eb@su-ai
Jerry Barber Gold Hill jerryb@mc
Jed Marti Rand marti@rand-unix
Chris Schmidt HPP schmidt@sumex
Alice Hartley BBN hartley@bbn
Gordon Novak Univ. of Texas novak@utexas-20
Guy Steele Tartan steele@tl-20a
Joe Ginder PERQ Joseph.Ginder@cmu-cs-spice
Jim Meehan Cognitive Sys. meehan@yale
Jonl White Xerox jonl@xerox
Neal Feinberg Symbolics feinberg@scrc-stony-brook
∂12-Nov-84 0012 GRISS%hp-hulk.csnet@csnet-relay.arpa Anybody there?
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 00:11:58 PST
Received: from hplabs by csnet-relay.csnet id aa05319; 12 Nov 84 3:01 EST
Received: by HP-VENUS id AA17087; Sun, 11 Nov 84 09:19:58 pst
Message-Id: <8411111719.AA17087@HP-VENUS>
Date: Sun 11 Nov 84 09:15:59-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Anybody there?
To: cl-subsets@su-ai.ARPA
Cc: GRISS@hplabs.CSNET
Source-Info: From (or Sender) name not authenticated.
This mailing list has been rather quiet the last few weeks, and I am
curious as to whether this reflects lack of interest, confusion as to
the next step, or distraction due to other things (e.g., elections,
cl-object-oriented-programming discussions, or ....).
We have a range of interests represented by people on this mailing
list, and I'd like to ask a few questions to get things rolling again.
1. What LISP or LISPs do you currently use?
2. Are you primarily a user or an implementor?
3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?
a. Ignore it
b. Hand translate code to CL and switch to some implementation
c. Develop a compatibility module for (a subset of) Common LISP
in your LISP.
d. Develop a translator for your LISP to Common LISP.
e. Convert or extend your LISP to include a significant
Common LISP subset.
f. Begin an implementation of CL on your hardware.
g. Other (?)
4. If you are a common LISP user or implementor, do you have a plan to
provide a compatibility route for "foreign" LISPS, such as by
mechanical translation, or compatibility module?
5. If your plan includes the identification of a subset CL
(perhaps because you only need or can only afford to implement
a subset on your machine, in your compatibility module, or
your translator),
could you summarize what criteria you are using to define your subset?
6. Some of the previous messages indicated that subsets were important for:
a. Small (weak, "unreal", "obselete") machines
b. Efficiency
c. Ease of implementatation
d. Interchange of code between workers who do not yet have a full CL
e. Export subsets for canned applications; some people
suggested a mechanical "disemboweling" would suffice,
but others felt this would make combining applications difficult.
f. Other (?)
For what reasons might you consider a subset?
7. Do you see a single subset as sufficient, or do you envision a family
of subsets, appropriate for different reasons?
8. Do you have a subset proposal ready to present to this group, or are
you working on one?
------------------------------------------------------------------------
I will send my own detailed responses to these questions shortly. I am
involved in examining CL subsetting issues with members of the
Standard LISP and PSL communities, here at Hewlett-Packard and
elsewhere.
Martin.
------------------------------------------------------------------------
-------
∂15-Nov-84 0537 brown@DEC-HUDSON Martin's questions
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 15 Nov 84 05:37:08 PST
Date: Thu, 15 Nov 84 08:37:23 EST
From: brown@DEC-HUDSON
Subject: Martin's questions
To: cl-subsets@su-ai
1. What LISP or LISPs do you currently use?
Vax Lisp (Dec Common Lisp) on a 780.
2. Are you primarily a user or an implementor?
Implementor
4. If you are a common LISP user or implementor, do you have a plan to
provide a compatibility route for "foreign" LISPS, such as by
mechanical translation, or compatibility module?
Not currently, we hope that such packages find their way into
the Yellow Pages (and might even be willing to help fund the
generation of these packages).
5. If your plan includes the identification of a subset CL
(perhaps because you only need or can only afford to implement
a subset on your machine, in your compatibility module, or
your translator),
could you summarize what criteria you are using to define your subset?
We currently have no plans to produce a subset of Common Lisp.
We distinguish between a subset and a self-contained program written
in Common Lisp which does not include all the language. We are
considering various mechanism which would allow a user to create
an executable program which would require less resource (memory)
than the full system.
7. Do you see a single subset as sufficient, or do you envision a family
of subsets, appropriate for different reasons?
I hope that, at least initially, one subset would be sufficient.
Any implementation could say "we implement Subset Common Lisp
plus ratios."
8. Do you have a subset proposal ready to present to this group, or are
you working on one?
The main thing I think is that the subset should be a true subset;
i.e. a program that is written purely in the subset is gaurenteed
to work in an implementation of full language. I believe this
requires that the subset be lexically scoped.
-Gary Brown
∂15-Nov-84 0744 FAHLMAN@CMU-CS-C.ARPA Martin's questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Nov 84 07:44:35 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 15 Nov 84 10:43:26-EST
Date: Thu, 15 Nov 1984 10:43 EST
Message-ID: <FAHLMAN.12063776476.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-subsets@SU-AI.ARPA
Subject: Martin's questions
1. What LISP or LISPs do you currently use?
Common Lisp (Spice Lisp) on a Perq. Occasionally also use Zetalisp on
3600 and Maclisp on Dec-20.
2. Are you primarily a user or an implementor?
Implementor
4. If you are a common LISP user or implementor, do you have a plan to
provide a compatibility route for "foreign" LISPS, such as by
mechanical translation, or compatibility module?
No serious plans at present. Several people here at CMU have converted
large Franz Lisp programs to Common Lisp, and we might be able to
package up the things they found they needed. We're working on a
portable flavor system, which could be viewed as a part of a Zetalisp
compatibility package or as an extension to Common Lisp.
5. If your plan includes the identification of a subset CL
(perhaps because you only need or can only afford to implement
a subset on your machine, in your compatibility module, or
your translator),
could you summarize what criteria you are using to define your subset?
We have no need for a subset. Rob Maclachlan has already developed a
technique for flushing any unused code from a Perq core image, giving a
dramatic size reduction for delivered stand-alone products.
7. Do you see a single subset as sufficient, or do you envision a family
of subsets, appropriate for different reasons?
The only need I see for a true subset is for small machines without
virtual memory, and even there they might get something approximating
the full language by a sort of autoload technique. In any event, such
system will be so tight that the builders will want to put in exactly
what their users need, and not some standard mix. For small expert
systems, you need one mix, for education you need another, if your
machine supports mouse-type graphics, another, if you want to build in
an Emacs, yet another. The speed-space tradeoffs are tricky, and
will be different for each tiny machine and each market. Maybe here and
there we will find cases enough alike that several manufacturers want to
agree on a common subset, or someone will set a de facto standard by
getting there first and doing a good job.
A different issue is the identification of a small kernel that, if you
can support it, you can load the rest of Common Lisp as portable code.
This is an interesting implementation technique, and we will be happy to
help people identify such kernels, but again the
time/space/coding-effort tradoff will be different for every machine,
depending on its constraints and whether it is trying to sit on top of
PSL, Interlisp, the raw hardware, or something else. Fortunately, no
standard is needed here, since on the surface all of these langauges
will look like real Common Lisp.
8. Do you have a subset proposal ready to present to this group, or are
you working on one?
Yes: no official subsets, but let's divide Common Lisp into standard
chunks so that people can say what it is that they do or do not
implement. (The validation suite should reflect these chunks.) Somone
might support "full Common Lisp minus floating point and complex
numbers, and with only partial support for packages" or something like
that.
-- Scott
∂22-Nov-84 1650 marti@randgr Martins Questions
Received: from RANDGR.ARPA by SU-AI.ARPA with TCP; 22 Nov 84 16:50:20 PST
Received: by randgr.ARPA; Tue, 20 Nov 84 09:25:27 pst
From: Jed Marti <marti@randgr>
Message-Id: <8411201725.AA10594@randgr.ARPA>
Date: 20 Nov 84 09:25:20 PST (Tue)
To: cl-subsets@su-ai
Subject: Martins Questions
1. What LISP or LISPs do you currently use?
| PSL mainly, some Franz and Interlisp.
2. Are you primarily a user or an implementor?
| User.
3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?
| For some projects where speed is of the essence, ignore it, unless
| something is done about efficiency. We plan simulations with large
| numbers of objects (like 10,000) and need the utmost in efficiency
| out of our small machines (SUN's).
4. If you are a common LISP user or implementor, do you have a plan to
provide a compatibility route for "foreign" LISPS, such as by
mechanical translation, or compatibility module?
| We have a machanical translator which currently operates between
| Interlisp, Franz Lisp, and PSL, as well as one under construction
| from Standard Lisp '79 to Common Lisp.
5. If your plan includes the identification of a subset CL
(perhaps because you only need or can only afford to implement
a subset on your machine, in your compatibility module, or
your translator),
could you summarize what criteria you are using to define your subset?
| Implementors Hat: Efficiency and speed of compilation. Features which
| slow down the generated object code will be looked at very carefully.
| Initially this includes the extendable arrays, and the four different
| floating point representations. A second criteria is frequency of use.
| The address space of the 8086, precludes a large library of seldom
| used functions. To this end we propose to make the complex and rational
| data structures part of a "load on call" library.
6. For what reasons might you consider a subset?
| Three reasons: small, weak, and obsolete machines such as the IBM PC, and
| the Apple MacIntosh. Efficiency! Efficiency!
7. Do you see a single subset as sufficient, or do you envision a family
of subsets, appropriate for different reasons?
| Possibly two subsets: An efficient subset, and an educational subset
| (maybe this should be a superset).
8. Do you have a subset proposal ready to present to this group, or are
you working on one?
| As part of the Standard Lisp user group, I have done some work in
| identifying problems with Standard Lisp to Common Lisp translation.
Jed Marti MARTI@RAND-UNIX
∂08-Dec-84 2156 REM
To: CL-SUBSETS@SU-AI.ARPA
[In reply to Griss's set of questions for members to answer:]
We have a range of interests represented by people on this mailing
list, and I'd like to ask a few questions to get things rolling again.
1. What LISP or LISPs do you currently use?
[My favorite among those I've used is MacLISP at MIT-MC, but since Stanford
no longer provides 1200-baud dialup access into the Arpanet I'm back at
300 baud to MIT-MC and I haven't used it much lately. I'm actively using
and developing PSL at IMSSS (Tenex) and PASC (VM/CMS). Long ago I used
Stanford LISP 1.6 and UCI-LISP, but gave them up long ago.]
2. Are you primarily a user or an implementor?
[Both. LISP is my language of choice for any task it can handle if I'm
on a machine that has it, although I occasionally have to write some
utility program in SAIL if LISP is too inefficient (the SCAN function
in SAIL is handy and very fast, I wish PSL had something like it) or if
I just happen to know how to write a one-shot task quickly in SAIL but
would have to do a lot of figuring to get it written in LISP. But for any
largescale program I always write in LISP, so I'm a major LISP user.
I write application software and general support utilities, but lately
at IMSSS for pay I'm getting into implementation of the kernel.]
3. For those of you who are currently using non-common LISP's, such as
InterLISP, FranzLISP, PSL, etc, what is your plan for Common LISP?
[Wait until CL is available on a machine I have access to, then give it
a try to see if it can do what I want at similar speed. If it takes twice
as long to run a program in CL as in PSL, I'll stay with PSL, otherwise
I'll probably try switching to CL. If I can get my hands on a translator
that works, I'll use it, else I'll manually do it with EMACS macros and
backwards-compatibility functions. (I already have such functions for
supporting various MacLISP, Standard-LISP, and personal functions in
terms of PSL primitives, such as ML-LET which is like LET in MacLISP
with destructuring which I use all over the place. I wish CL had
destructuring available. In any case I will keep programming in some
form of LISP until something better comes along, which is unlikely.]
5. If your plan includes the identification of a subset CL
(perhaps because you only need or can only afford to implement
a subset on your machine, in your compatibility module, or
your translator),
could you summarize what criteria you are using to define your subset?
[The mimimal subset should run on an Altair 8800a (8080 cpu) with 28k bytes
of RAM. A little more reasonable subset should run on an IBM PC with the
minimum memory configuration that starting computer users might already
have bought. A really decent subset should run on a PDP-10 under Tenex.]
6. Some of the previous messages indicated that subsets were important for:
For what reasons might you consider a subset?
[For running on small machines, and to simplify bootstrapping on a new machine.]
7. Do you see a single subset as sufficient, or do you envision a family
of subsets, appropriate for different reasons?
[Mostly I see a heirarchy of subsets, from bare-minimum to whole ball of
wax and can of worms, with possible branches like bare-minimum with
floating point but not packages, or packages but not floating point, etc.]
8. Do you have a subset proposal ready to present to this group, or are
you working on one?
[I have no formal proposal at this time, but a while back I went through a
LISP manual identifying those functions which were absolutely essential to
get any LISP running at all, versus those which had their uses but weren't
essential in every program. I think fewer than a hundred functions were
in the former category. If somebody is interested I can fish out my notes
and send my DRASTIC-TEENSY-TINY-LISP subset proposal as a starting point
for very-minimal subset discussions.]
∂08-Dec-84 2225 REM
To: CL-SUBSETS@SU-AI.ARPA
From: brown@DEC-HUDSON
The main thing I think is that the subset should be a true subset;
i.e. a program that is written purely in the subset is gaurenteed
to work in an implementation of full language. I believe this
requires that the subset be lexically scoped.
[I disagree with that conclusion. There are several ways that one LISP
can be a subset of another: (1) it can be missing some of the functions,
(2) it can be missing some of the datatypes, (3) some of the functions
can know about and be able to handle fewer of the kinds of situations,
be less flexible, have fewer options, (4) some of the overall mechanisms
can be less capable.
These are mostly but not totally orthogonal. ACOSH and ASINH can be missing
even if floating point and complex values are available, thus having
the datatype doesn't imply all the functions to handle it are around.
The converse, ASINH and ACOSH are available but they don't handle floating
point, is probably impossible in CL. Thus they are orthogonal in one
direction. Ratios might not be implemented, which would mean that READ
would have to bomb out if it encountered the syntax for a ratio, and
division of integers couldn't be implemented in all cases either. Thus
there is some linkage between datatypes available and case that READ and
/ are equipped to handle. Finally, to rebut the assertion claimed above,
a subset of CL might not have lexical closures implemented and might work
correctly only on programs that have no undeclared free variables, it might
even have no optional or rest arguments. A program written in this restricted
subset would work fine in full blown CL, with identical semantics. Thus a
subset needn't have lexical scoping. -- For the mathematicians, the null
language that has no functions and no datatypes, is a subset of CL, and
is an obvious counterexample to the claim that any subset of CL must have
lexical scoping. But I think there could be reasonable non-null subsets that
are easy to implement on small machines or to define in existing systems
such as PSL, which don't have lexical scoping yet are true subsets.
I think we should be aware of the several dimensions of subsetting, some
of which I listed above, and consider all those dimensions when defining
a subset, not just what functions are defined. When we define a subset,
we should clearly document what functions aren't there at all, what functions
are implemented in lesser ways, what datatypes are missing, what features
of general code writing are missing (implicit PROGNs, lexical closures, ...),
any other differences. Alternately for really drastic subsets just say what
the subset is and indicate explicitly in the rare cases when the fullblown
version of some function is defined. Anyone agree or disagree or amend?]
∂09-Dec-84 0803 FAHLMAN@CMU-CS-C.ARPA
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Dec 84 08:03:37 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Dec 84 11:04:08-EST
Date: Sun, 9 Dec 1984 11:04 EST
Message-ID: <FAHLMAN.12070071698.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Robert Maas <REM@SU-AI.ARPA>
Cc: CL-SUBSETS@SU-AI.ARPA
In-reply-to: Msg of 9 Dec 1984 01:25-EST from Robert Maas <REM at SU-AI.ARPA>
REM makes a useful point, I think: a dynamically scoped implementation
can be a "true subset" of Common Lisp as long as the cases where the
diference can be seen are not allowed (or are not used in portable
code). This could be as simple as requiring Special declarations around
any variable used free.
Enumerating the ways in which one language can be a subset of another is
useful, but I think it's important to keep the definition of "true
subset" in mind: if you're writing code in a true subset of Common Lisp,
your code will run in any full implementation of Common Lisp without
modification. One can also envision "near subsets" in which the code
has to be modified in order to run in Common Lisp, but in which the
modifications are straightforward and perhaps can be done automatically.
My suggestion to DARPA has been that they should not bless any
particular subset, but that where code from many different systems must
ultimately run together (as in some parts of the Strategic Computing
program) they simply require that the code ultimately produced must run
in any full implementation of Common Lisp. Researchers would be free to
write in a full Common Lisp, any "true subset", or a "near subset" if
they are willing to periodically do that translation. They could even
do their research in some very diferent Lisp and then hand-translate the
result, though that is obviously doing it the hard way. This way we do
not penalize people working in full Common Lisp (that would be
counter-productive to the goal of moving toward Common Lisp as a
standard), while providing the maximum flexibility for people who are
working in other implementations.
The only reason I can see for blessing some particular subset is so that
people working in this subset can trade code among themselves, though
they could not in general run code written in unrestricted Common Lisp,
of which there will be an ever-increasing amount. A very minimal
"interchange subset" that can easily be implemented on top of PSL,
Interlisp, Franz, and maybe T would be of some value, but only if it is
not TOO much more restricted than the intersection of any one of these
languages with full Common Lisp. My guess is that whenever a full
Common Lisp appears on any family of machines, people will start using
that and stop using the interchange subset.
-- Scott
∂09-Dec-84 1255 RPG
∂08-Dec-84 2104 REM
To: CL-SUBSETS-REQUEST
Please put REM@IMSSS on the list. I don't think IMSSS is currently in
any name domain, or if it is I don't know what it would be, but mail
can be forwarded via SU-SCORE.ARPA by using this address from the
Arpanet: REM%IMSSS@SCORE.ARPA from SU-AI it's a little harder because @
is reserved as a command to read text from an indirect file, so you
have to say "REM%IMSSS"%SCORE from here.
I think Common LISP as defined has a plethoria of seldom-used functions
and defining a workable subset for tiny machines (8080/z80 with 2↑16
bytes of memory or less) and small machines (PDP-10 with 2↑18 36-bit words)
is necessary if this is to be a truly common implementation instead of
a snob language for those with 68000 or LISPM or VAX or IBM-4033
that won't run on any smaller machine.
∂17-Feb-85 1820 fkunze%ucbopal.CC@Berkeley Please add the following names to the subset list
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 17 Feb 85 18:20:15 PST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.41)
id AA13429; Sun, 17 Feb 85 18:21:15 pst
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
by ucbjade.CC.Berkeley.ARPA (4.19/4.33.1)
id AA05206; Sun, 17 Feb 85 18:21:59 pst
Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.33)
id AA03905; Sun, 17 Feb 85 18:21:44 pst
Date: Sun, 17 Feb 85 18:21:44 pst
From: fkunze%ucbopal.CC@Berkeley (Fritz Kunze)
Message-Id: <8502180221.AA03905@ucbopal.CC.Berkeley.ARPA>
To: CL-subsets@su-ai.ARPA
Subject: Please add the following names to the subset list
Fritz Kunze fkunze%franz.uucp@ucbkim.arpa
John Foderaro jkf%franz.uucp@ucbkim.arpa
Both people are from Franz Inc.
Thanks.
--Fritz Kunze